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Enciyption Key Updating for Multiple Site Automated Login 



Field of the Invention 

This invention relates generally to the field of computers, and in 
5 particular to automatically updating keys used to log into multiple sites. 

Copyright Notice/Permission 

A portion of the disclosure of this patent document contains material 
which is subject to copyright protection. The copyright owner has no objection 
10 to the facsimile reproduction by anyone of the patent document or the patent 

disclosure as it appears in the Patent and Trademark Office patent file or records, 
but otherwise reserves all copyright rights whatsoever. The following notice 
applies to the software and data as described below and in the drawing hereto: 
Copyright © 2000, Microsoft Corporation, All Rights Reserved. 

15 

Background 

The recent growth in popularity of the Internet has significantly increased 
the number of Internet users and the number of Internet sites (also referred to as 
"web sites"). Web sites may provide various types of information to users, offer 

20 products or services for sale, and provide games and other forms of 

entertainment. Many web sites require users to "register" by providing 
information about themselves before the web server grants access to the site. 
This registration information may include the user's name, account number, 
address, telephone number, email address, computer platform, age, gender, or 

25 hobbies. The registration information collected by the web site may be 
necessary to complete transactions (such as commercial or financial 
transactions). Additionally, information can be collected which allows the web 
site operator to learn about the visitors to the site to better target its future 
marketing activities or adjust the information provided on the web site. The 

30 collected information may also be used to allow the web site to contact the user 
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directly (e.g., via email) in the future to announce, for example, special 
promotions, new products, or new features of the web site. 

When registering with a web site for the first time, the web site typically 
requests that the user select a login ID and an associated password. The login ID 
5 allows the web site to identify the user and retrieve the user's information during 
subsequent u ser visits to the web site. Generally, the login ID must be unique to 
the web site such that no two users have the same login ID. The password 
associated with the login ID allows the web site to authenticate the user during 
subsequent visits to the web site. The password also prevents others (who do not 
10 know the password) from accessing the web site using the user's login ID. This 
password protection is particularly important if the web site stores private or 
confidential information about the user, such as financial information or medial 
records. 

If a user visits several different web sites, each web site may require 

15 entry of similar registration information about the user, such as the user's name, 
mailing address, and email address. This repeated entry of identical data is 
tedious when visiting multiple web sites in a short period of time. Many web 
sites require the user to register before accessing any information provided on 
the web site. Thus, the user must enter the requested registration information 

20 before they can determine whether the site contains any information of interest. 

After registering with multiple web sites, the user must remember the 
specific login ID and password used with each web site or other Internet service. 
Without the correct login ID and password, the user must re-enter the 
registration i iformation. A particular user is likely to have different login IDs 

25 and associated passwords on different web sites. For example, a user named 
Bob Smith rr ay select "smith" as his login ID for a particular site. If the site 
already has a user with a login ID of "smith" or requires a login ID of at least six 
characters, then the user must select a different login ID. After registering at 
numerous web sites, Bob Smith may have a collection of different login IDs, 

30 such as: smith, smithl, bsmith, smithb, bobsmith, bobsmith, and smithbob. 
Further, different passwords may be associated with different login IDs due to 
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differing password requirements of the different web sites (e.g., password length 

requirements; or a requirement that each password include at least one numeric 

character). Thus, Bob Smith must maintain a list of web sites, login IDs, and 

associated passwords for all sites that he visits regularly. 
5 Some sites keep track of this login information for the user, and provide a 

key ring, which is essentially set of images or icons which when selected provide 

login information to a site associated. 

There is a need for a secure way to log in to multiple sites. There is a 

further need to be able to change security parameters on sites without 
10 interrupting i:he user or site. There is yet a further need to manage security for 

multiple sites in a multiple site login service in a simple and uncomplicated 

manner. 



Summary of the Invention 

15 New keys for decrypting automatic login information are distributed, and 

may coexist with a current key. Following a selected time, the new key becomes 
the current key. 

During the period of coexistence of keys, a multiple site login service 
which issues the tickets begins to send tickets to the sites which may be 

20 decrypted by use of the new key. Following a period of time at least as long as 
the coexisterce period, the old keys are expired and no longer available for use. 
A configuration file is used to keep track of sites logged into as well as a login 
ID and password for each site. As a site is visited by the user, the ticket is 
created from this information. Each key has a version tag associated with it. 

25 When an updated key is issued by the login service, the version tag is 
incremented or otherwise changed. 

The site usually has a predetermined reauthorization period, after which 
each user is required to reauthenticate to the site again. The login service 
provides the ticket again for reauthorization. By setting the selected time for the 

30 new key to become the current key, all users currently logged into a site will not 
see a difference in operation. By the time the selected time passes, all users 
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logged into the site will have already reauthorized using a ticket corresponding 
to the new key. 

An individual site may request a new key, as may the login service. In 
one aspect of the invention, the login service generates a new key for a site to 
ensure that a minimum level of security of the site is maintained. 

Brief Description of the Drawings 

Fig. 1 is a block diagram showing pertinent components of a computer in 

accordance with the invention. 
Fig. 2 illustrates an exemplary network environment in which the present 

invention is utilized. 
Fig. 3 is a block diagram showing components involved in key generation, 

distribution, updating and use. 

Detailed Description 

In the following detailed description of exemplary embodiments of the 
invention, reference is made to the accompanying drawings which form a part 
hereof, and in which is shown by way of illustration specific exemplary 
embodiments in which the invention may be practiced. These embodiments are 
described in sufficient detail to enable those skilled in the art to practice the 
invention, ard it is to be understood that other embodiments may be utilized and 
that logical, mechanical, electrical and other changes may be made without 
departing from the spirit or scope of the present invention. The following 
detailed description is, therefore, not to be taken in a limiting sense, and the 
scope of the present invention is defined only by the appended claims. 

The detailed description is divided into multiple sections. A first section 
describes a simple representation of a computer system and the operation of 
multiple computer systems on a network which implement different aspect of the 
current inver tion. This is followed by a description of the invention and how it 
is implemented. 
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Hardware and Operating Environment 
An exemplary system for implementing the invention includes a 
computing device, such as computing device 100 in Fig. 1 . In its most basic 
configuration, computing device 100 typically includes at least one processing 
unit 102 and memory 104. Depending on the exact configuration and type of 
computing device, memory 104 may be volatile (such as RAM), non- volatile 
(such as RO VI, flash memory, etc.) or some combination of the two. This most 
basic configuration is illustrated in Fig. 1 by broken line 106. 

Device 100 may also include additional features/functionality. For 
example, device 100 may include additional storage (removable and/or non- 
removable) including, but not limited to, magnetic or optical disks or tape. Such 
additional storage is illustrated in Figure 1 by removable storage 108 and non- 
removable slorage 1 10. Computer storage media includes volatile and 
nonvolatile, removable and non-removable media implemented in any method of 
technology for storage of information such as computer readable instructions, 
data structures, program modules or other data. Memory 104, removable storage 
108 and non -removable storage 1 10 are all examples of computer storage media. 
Computer slorage media includes, but is not limited to RAM, ROM, EEPROM, 
flash memory or other memory technology, CD-ROM, digital versatile disks 
(DVD) or other optical storage, magnetic based storage or any other medium 
which can be used to store desired information and which can be accessed by 
device 100. Any such computer storage media may be part of device 100. 

Device 100 may also contain communications connection(s) 112 that 
allow the device to communicate with other devices. Communications 
connection(s) 1 12 is an example of communication media. Communications 
media typically embodies computer readable instructions, data structures, 
program modules or other data in a modulated data signal such as a carrier wave 
or other transport mechanism and includes any information delivery media. The 
term "modulated data signal" means a signal that has one or more of its 
characteristics set of changed in such a manner as to encode information in the 
signal. By way of example, and not limitation, communication media includes 
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wired media such as wired network or direct-wired connection, and wireless 
media such as acoustic, RF, infrared and other wireless media. The term 
computer readable media as used herein includes both storage media and 
communications media. 
5 Device 100 may also have input device(s) 1 14 such as keyboard, mouse, 

pen, voice input device, touch input device, etc. Output device(s) 116 such as 
display, speakers, printers, etc may also be included. All these devices are well 
known in the art. 

This invention may be described in the context of computer-executable 

10 instructions, such as program modules, executed by one or more computer or 
other devices such as device 110. Generally, program modules include routines, 
programs, objects, components, data structures, etc. that perform particular tasks 
or implement particular abstract data types. Typically the functionality of the 
program modules may be combined or distributed as desired in various 

15 embodiments. 

Fig. 2 is a block diagram illustrating an exemplary network environment 
in which the present invention is utilized. A client computer system 200 is 
coupled to a network 202. In this example, network 202 is the Internet (or the 
World-Wide Web). However, the teachings of the present invention can be 

20 applied to any data communication network that implements a stateless protocol 
similar to hypertext transfer protocol, http. Multiple affiliate servers 204, 206, 
and 208 are coupled to network 202, thereby allowing client computer system 
200 to access web servers 204, 206, and 208 via the network. Affiliate servers 
204, 206, and 208 are also referred to as "web servers", "network servers" and 

25 "sites" hosting content such as text and images for access by other computers on 
the network 202. An authentication server 210 is also coupled to network 202, 
facilitating communication between the authentication server and client 
computer system 200 and authentication servers 204, 206, and 208. Although 
referred to as; an "authentication server", authentication server 210 is also a web 

30 server capab e of interacting with web browsers and other web servers. In this 
example, data is communicated between the authentication server 210, client 
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computer system 200, and web servers using http, a protocol commonly used on 
the Internet :o exchange information. An http specification is published by the 
Internet Engineering Task Force. 

An authentication database 212 is coupled to authentication server 210. 
5 The authentication database 2 1 2 contains information necessary to authenticate 
users and also identifies which elements of user profile information should be 
provided to a particular affiliate server when the user accesses the affiliate 
server. Although the authentication database 212 is shown separately from the 
authentication server 210, in other embodiments of the invention, the 

10 authentication database is contained within the authentication server. 

An authentication process authenticates a user of client computer 200 
seeking access to an affiliate server 204, 206, or 208. The authentication server 
210 authenticates the user of client computer 200 by requesting authenticating 
information, such as the user's login ID and password. If the user is successfully 

1 5 authenticated, then authentication server 2 1 0 generates an encrypted 

authentication ticket and communicates the ticket to the appropriate affiliate 
server. The authentication ticket indicates that the user is authenticated. Each 
affiliate server requires a key in order to decrypt the ticket and allow access by 
the user. 

20 The authentication ticket contains two time stamps. The first time stamp 

indicates the last time that the user's login ID and password were physically 
typed by the user. The second time stamp indicates the last time that the user's 
login information was refreshed by the authentication server. This "refresh" of 
the user's login information can be performed "silently" or by manual entry of 

25 the login information (i.e., login ID and password) by the user. The refreshing of 
the user's login information is performed by the authentication server. Once 
completed, a new authentication ticket is issued to the affiliate server indicating 
the new time stamp values. 

The term "affiliate server" is defined herein as a web server that has 

30 "registered" or established a relationship or affiliation with the authentication 

server 210. Each affiliate server 204, 206, and 208 includes a code sequence that 
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allows the affiliate server to communicate with the authentication server 210 
when a user (who is also registered with the authentication server) requests 
access to the affiliate server. 

Prior to executing the authentication process, both the user of client 
5 computer system 200 and the operator of affiliate server 204 "register" with the 
authentication server 210. This registration is a one-time process which provides 
necessary information to the authentication server. The user of client computer 
system 200 registers by providing information such as the user's email address, 
password information, and various other information about the user or the client 

10 computer system if desired. As part of the user registration process, the user is 
assigned (or selects) a login ID, which is a common login ID used to access any 
affiliate server. The login ID may also be referred to herein as a "user name" or 
"login name". Additionally, the user selects a password associated with the 
login ID which is used for authentication purposes. 

15 After registering and logging into the authentication server, the user can 

visit any affiliate server (i.e., affiliate servers that are also registered with the 
same authentication server) without requiring any additional authentication and 
without re-entering user information that is already contained in the associated 
user profile. 

20 The operator of affiliate server 204 registers with the authentication 

server 210 by providing information about the affiliate server (e.g., server name 
and internet address). Additionally, the affiliate server provides information 
regarding its authentication requirements. The authentication requirements can 
be specified as the maximum time allowed since the last login and entry of 

25 authentication information by the user as well as the maximum time allowed 

since the last "refresh" of the authentication information by the user. Refreshing 
the authentic ation information refers to the process of having the user re-enter 
the password to be certain that the appropriate user is still operating the client 
computer system. This periodic refreshing of authentication information is 

30 useful if the user leaves their computer system without logging out of the 
authentication server, thereby allowing another individual to access affiliate 
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servers using the login ID of the previous user. If a user requests access to the 
affiliate server after the maximum time allowed, then the user is re-authenticated 
(i.e., refreshed) by the authentication server by issuing a new authentication 
ticket either silently or with required reentry of password as described above. 
5 Thus, although there is a central authentication server, each individual affiliate 
server can establish its own authentication requirements which are enforced by 
the authentication server. After registering with the authentication server, the 
affiliate server can use the authentication server to authenticate any user that has 
also registered with the authentication server. 

10 A block diagram showing the general operation of key generation and 

distribution for decrypting tickets is provided in Fig. 3. The authentication 
server has several servers associated with it. A nexus server 310 manages a 
configuration file, which contains information regarding partner sites in the form 
of a partner.xml, information about keys in a keys.xml, and information about 

1 5 the network server in a networkserver.xml in the configuration file. These XML 
files are each a component configuration document (CCD). Further associated 
servers include a login server, which provide login services, a register server, and 
a logout server. Each of these servers may be integrated into a single server, or 
comprise multiple servers themselves. 

20 A key generator 345 is also associated with the authentication server. It 

has an administrative interface 350 that allows selection of new keys by a user, 
and provides; keys in the form of an executable piece of code referred to as 
key.exe via a network 360 (shown in two places for convenience) such as the 
Internet, to one or more affiliate servers such as a partner site 370. Partner site 

25 370 may have several servers operating as indicated in Figure 3, all servicing the 
same network domain. The key generator also provides the keys.xml 
information to the nexus, where it is stored in the configuration file. 

When a new partner site is registered by use of the register server 330, a 
key is generated for the site and provided by S-MIME secure encrypted email, 

30 using standard certification, or physically mailed to operators of the site for 

installation. The key is delivered as an EXE with key data embedded within it. 
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An object, such as a COM object handles installation and encryption of the keys. 
The first key has a version number, such as "1", and is stored by the site in 
encrypted form in a registry using a piece of information that is specific to the 
physical machine, such as the MAC address of the first network card. The 
5 key.exe is used for decrypting tickets while the authentication server is still 
running. 

The administrative interface 350 is used to cause generation of a new 
sitelD for the new partner site, and generation of the key for that site with a one 
digit Hex version tag or number of "1". Other lengths of version numbers may 

10 used as desired. Interface 350 updates the nexus server 310 with information 
about the paitner, such as site ID, keys.xml and current version number. Since 
there may be multiple trusted servers, i.e.: login servers, each is then triggered to 
refresh configuration information from the nexus server 310, including the new 
keys.xml file: with the new site's key version "1" included. The keys are 

15 distributed as a distinct private secure CCD in clear text over a highly secure 

(128-bit SSL) channel that is both client and server authenticated. Each time the 
CCD is retrieved by a trusted server, all the keys are immediately encrypted and 
stored in a registry, and then the CCD is completely thrown away. 

When a new key is to be updated, telephone or email is used to initiate 

20 the generation of a new key. Such generation could also be automated if desired. 
The key may be updated on a regular schedule or variable schedule when 
initiated on the authentication server side, or may be initiated in accordance with 
various security protocols on either the authentication server side or partner site 
side. The partner site administrators may request a new key when an employee 

25 leaves, or any time desired. 

A new key is then generated at 345 and is updated on the nexus server 
310 to add the new key to a list of keys for the partner's sitelD in the 
configuration file. The version number is incremented. When it reaches "F", it 
loops back to one and resumes incrementing over time. 

30 Key generator 345 also generates a key.exe file that can be installed on 

the partner site servers. The new key.exe file is sent securely to the partner and 
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received. The key.exe file is then run against all servers on the partner site with 
an "/addkey" parameter that installs the new key onto the server while still 
running. It is added as an additional key with no expiration date. 

Next, the partner site runs the key.exe file against all servers with a 
5 "/makecurrejit" parameter to make the new key the current key by switching a 
registry key referred to as keycurrent to the new key version. They registry my 
also take the form of a config file, or any file in other systems. It also sets an 
expiration date on the previous current key equal to the current time plus a 
registry key value referred to as Time Window. Time window may be set equal 
10 to the reauthorization time, or any other desired time. It may also be set to zero 
to immediately begin exclusive use of the new current key to access the partner 
site. If no time window has been set, old keys are flushed every 24 hours or so if 
desired. 

Key.exe may also be run against all servers using an "/expire" parameter 

15 prior to receiving a new key to cause a service interruption until new keys are 
installed. This ensures that no new tickets using an old compromised key are 
accepted, and the old key can be immediately deleted from all servers. 

The manager at each site 370 uses several registry keys to keep track of 
encryption keys. A SitelD is the partner site's ID and is used in all calls to the 

20 authentication server. A Time Window is essentially the site's default preference 
for how "fre:3h" a user's ticket must be before they are redirected back to the 
login server for a new key. KeyData contains the actual keys, encrypted in the 
HMAC of the machine. Each encryption key is stored as a value of this registry 
key, with the version stamp as the value's name, and the encrypted key data as 

25 the value's data. These values map one to one with values under KeyTimes. 
Key Times specifies the expiration dates of all the keys referenced in KeyData. 
For each encryption key, this registry key will contain a value whose name is the 
encryption key's version stamp, and whose data is the date and time at which this 
key is no lor.ger valid. The value "-1" signifies that the key never expires. 

30 Typically, keys are set to never expire until it is time to update the key. 
CurrentKey is the version stamp of the current key. The version stamp is 
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referenced in all requests to authentication servers. It indicates which key this 

server expects to get new tickets in. 

When there is a new key, users that are currently logged on will be able 

to continue their session using the old key. When Key Times expires, they must 
5 use the new key to reauthorize their session. When this happens, or when a new 

user attempts to log in with an older version ticket after key.exe has been run 

with MakeCurrent, the partner site receives an attempt to log in by the user using 

the old ticket. When parsing a ticket with an expired key, it is rejected, the user 

gets redirected to the login server URL with parameters "ID=xxx&KV=2" used 
10 to specify ths new encryption key. The user is redirected by this URL to the 

login server. This redirection causes the login server to update the configuration 

file to indicate that the new key is now the current key. 

A new ticket is generated using the new key. As each new user or 

reauthorization request is received for that site, the new current key will be used 
15 to generate the ticket. In its unencrypted form, the ticket sent by the user 

comprises authentication time stamps and user information. When encrypted, it 

takes the form of: "keyversion#, string", where the string is an encrypted form of 

the timestamps and user information. 

20 Conclusion 

The key generation and distribution process provides a safe, reliable way 
of distributing keys to partner sites that requires minimal human intervention, 
little if any user disruption, and minimal operational disruption. While parts of 
the process have been described in terms of human operations, these operations 
25 may be easily automated. In the same manner, automated operations may also 
be performed by human actions. The process allows two keys to be operative for 
a desired amount of time. 
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We claim: 



1 . A method of updating keys that decrypt login tickets that log a user into 
multiple sites, the method comprising: 

5 generating a first key having a first version number; 

providing tickets encoded consistent with the first key, the ticket having a 
version number corresponding to the first version number; 

generating a second key having a second version number; and 
when the second key becomes current at a site, providing tickets encoded 
10 consistent with the second key, the ticket having a version number 
corresponding to the second version number. 

2. The method of claim 1 wherein a different key is provided to each site, 
and wherein each key is encrypted for decoding at one site. 

15 

3. The method of claim 1 and further including generating a configuration 
file to track keys for each site. 

4. The method of claim 1 wherein the key comprises key data and 
20 executable code for decrypting tickets. 

5. A computer readable medium having instructions stored thereon for 
causing a computer to perform a method of updating keys that decrypt login 
tickets that log a user into multiple sites, the method comprising: 

25 generating a first key having a first version number; 

providing tickets encoded consistent with the first key, the ticket having a 
version number corresponding to the first version number; 

generating a second key having a second version number; and 
when the second key becomes current at a site, providing tickets encoded 
30 consistent with the second key, the ticket having a version number 
corresponding to the second version number. 
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6. A method of generating keys that decrypt login tickets that log a user into 
multiple sites, the method comprising: 

generating a first key in the form of an executable having a first version 
number; 

5 generating a second key in the form of an executable having a second 

version number; and 

providing an indication to a login server identifying which key is current 
for each site such that the tickets are properly encoded. 

10 7. The method of claim 6 and further comprising distributing the key to 
multiple login servers in a secure manner. 

8. The method of claim 6 and further comprising updating a configuration 
file to track keys for each site. 

15 

9. A computer readable medium having instructions stored thereon for 
causing a computer to perform a method of generating keys that decrypt login 
tickets that log a user into multiple sites, the method comprising: 

generating a first key in the form of an executable having a first version 
20 number; 

generating a second key in the form of an executable having a second 
version number; and 

providing an indication to a login server identifying which key is current 
for each site such that the tickets are properly encoded. 

25 

10. A system that generates keys that decrypt login tickets that log a user into 
multiple sites, the system comprising: 

a key generator that generates a first key in the form of an executable 
having a firs : version number and generates a second key in the form of an 
30 executable having a second version number; and 
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means for providing information to a login server identifying which key 
is current for each site such that the tickets are properly encoded. 

11. A method of updating keys that decrypt login tickets that log a user into 
5 multiple sites, the method comprising: 

generating a new key with an incremented version number; 

sending the new key to a partner site for use in decoding tickets with the 
incremented version number; 

updating key and version information for a login server; and 
10 generating tickets decodable by the new key when an indication that a 

key having a previous version number has expired. 

12. A computer readable medium having instructions stored thereon for 
causing a computer to perform a method of updating keys that decrypt login 

15 tickets that log a user into multiple sites, the method comprising: 
generating a new key with an incremented version number; 
sending the new key to a partner site for use in decoding tickets with the 
incremented version number; 

updating key and version information for a login server; and 
20 generating tickets decodable by the new key when an indication that a 

key having a previous version number has expired 

13. A method of updating a key used to decrypt tickets used to log into a site, 
the method comprising: 

25 receiving an updated key with a new version number; 

setting a time for an old current key having an old version number to 

expire; 

making the updated key the current key. 

30 14. The method of claim 13 wherein the key comprises executable code for 
making the updated key the current key. 
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15. The method of claim 1 3 and further comprising redirecting users 
attempting to log into the site using the old current key. 

16. A computer readable medium having instructions stored thereon for 
causing a computer to perform a method of updating a key used to decrypt 
tickets used to log into a site, the method comprising: 

receiving an updated key with a new version number; 

setting a time for an old current key having an old version number to 

expire; 

making the updated key the current key. 

1 7. A method of updating a key used to decrypt tickets used to log into a site, 
the method comprising: 

receiving an updated key with a new version number; 
setting a time for an old current key having an old version number to 
expire; and 

making the updated key the current key. 

18. A co mputer readable medium having instructions stored thereon for 
causing a computer to perform a method of updating a key used to decrypt 
tickets used to log into a site, the method comprising: 

receiving an updated key with a new version number; 
setting a time for an old current key having an old version number to 
expire; and 

making the updated key the current key. 

19. A method of managing keys used to decrypt tickets for logging onto a 
site, the method comprising: 

receiving a first key with a first version number; 
encrypting the first key using a hardware address; 
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changing a current key variable to the first version number; 
receiving a new key with an incremented version number; 
encr>pting the new key using a hardware address; and 
identifying the new key as the current key. 

5 

20. Them method of claim 19 and further comprising setting a time for the 
first key identifying when such key may no longer be used. 

2 1 . The method of claim 20 wherein a user currently logged in may continue 
10 to use the first key until the time expires. 

22. The method of claim 20 wherein new user may only use a ticket 
corresponding to the second key when the second key is made the current key. 

15 23. The method of claim 20 wherein the time is set to a reauthorization time 
determined by the site. 

24. The method of claim 19 wherein a new user using a previous version 
ticket will be redirected to obtain a ticket corresponding to the new key 

20 following the new key being identified as the current key. 

25. The method of claim 19 wherein the new key is identified as the current 
key by changing the current key variable to the second version number. 

25 26. A computer readable medium having instructions stored thereon for 
causing a computer to perform a method of managing keys used to decrypt 
tickets for logging onto a site, the method comprising: 
receiving a first key with a first version number; 
encrypting the first key using a hardware address; 
30 changing a current key variable to the first version number; 

receiving a new key with an incremented version number; 
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encrypting the new key using a hardware address; and 
identifying the new key as the current key. 

27. A method of updating keys used to decrypt tickets used to log into 
5 multiple sites on a network, the method comprising: 

generating a new key with a new version number to take the place of an 
old key with an old version number; 

storing the new key on a site to be logged into by a user; 

changing a current key indication to the new key; 
10 allowing current logged in users to continue using the old key; and 

redirecting new users to a login server to obtain a ticket consistent with 
the new key. 

28. The method of claim 27 wherein the old key may be used by current 
15 logged in users for a predetermined amount of time. 

29. The method of claim 28 wherein the predetermined amount of time is no 
more than a reauthorization time by which a current user is normally required to 
provide login information. 

20 

30. The method of claim 28 wherein the predetermined amount of time may 
be set to zero to force all current and new users to login with a ticket consistent 
with the new key version. 

25 31. The method of claim 27 wherein the ticket contains a version number 
consistent with the version number of the key which can decrypt it. 

32. The method of claim 27 wherein keys are encrypted by the site using a 
hardware address, and stored by the site. 

30 
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33 . The method of claim 27 wherein a new key is generated based on a 
request of the site. 

34. The method of claim 27 wherein keys are generated in an executable 

5 form which includes key information as well as code for decrypting tickets using 
the key information. 

35. The riethod of claim 27 wherein the keys are generated by an 
authentication server, and are distributed to multiple login servers for providing 

10 login tickets. 

36. A computer readable medium having instructions stored thereon for 
causing a computer to perform a method of updating keys used to decrypt tickets 
used to log into multiple sites on a network, the method comprising: 

1 5 generating a new key with a new version number to take the place of an 

old key with an old version number; 

storing the new key on a site to be logged into by a user; 
changing a current key indication to the new key; 
allowing current logged in users to continue using the old key; and 
20 redirecting new users to a login server to obtain a ticket consistent with 

the new key. 

37. A method of logging on to multiple sites, the method comprising: 
sending a first login ticket to a desired site, wherein the login ticket is 

25 encrypted to be decoded by a first key having a first version number; 
receiving an indication that the first key has expired; 

obtaining a second login ticket from an authentication server, wherein the 
second login ticket is encrypted consistently with a new key having a second 
version number; and 
30 sending the second login ticket to the site to log into the site. 
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3 8 . The method of claim 3 7 wherein the tickets contain a version number 
which is readable without decryption. 

39. The method of claim 38 wherein the version number is a one digit Hex 
5 integer. 

40. The method of claim 38 wherein the encrypted ticket comprises an 
unencrypted version number, and encrypted information sufficient to log a user 
into a desirec. site. 

10 

41 . A computer readable medium having instructions stored thereon for 
causing a computer to perform a method of logging on to multiple sites, the 
method comprising: 

sending a first login ticket to a desired site, wherein the login ticket is 
15 encrypted to be decoded by a first key having a first version number; 
receiving an indication that the first key has expired; 
obtaining a second login ticket from an authentication server, wherein the 
second login ticket is encrypted consistently with a new key having a second 
version number; and 
20 sending the second login ticket to the site to log into the site. 

42. An encrypted ticket for use in logging on to a website, the ticket 
comprising: 

an unencrypted version number corresponding to a key version number 
25 stored on the website; and 

an encrypted string identifying the website and information, which when 
decrypted using the key having the same version number authenticates the user 
for logging the user into the website. 
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Abstract of the Disclosure 



A version number is associated with an encrypted key executable to 
allow real time updating of keys for a system which facilitates users signing on 
to multiple websites on different domains using an encrypted ticket. Two keys 

5 may be used at each site during updating of keys, each having an associated one 
digit Hex version tag. When a key is to be updated with a new key, the existing 
or old key is provided an expiration time. A second key is provided from the 
system in a secure manner with a new version number and made the current key 
which provides decryption of the encrypted ticket. The system tracks both keys 

10 while they are concurrent. After the existing key expires, only the second, or 
updated key is used to provide login services for users. The system periodically 
flushes old keys. 
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As a below named inventor I hereby declare that: my residence, post office address and citizenship are as 
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I verily believe I am the original, first and joint inventor of the subject matter which is claimed and for which 
a patent is sought on the invention entitled: KEY DISTRIBUTION . 

The specification of which is attached hereto. 

I hereby state that I have rev iewed and understand the contents of the above-identified specification, 
including the claims, as amended by any amendment referred to above. 

I acknowledge the duty to disclose information which is material to the patentability of this application in 
accordance with 37 C.F.R. § 1.56 (attached hereto). I also acknowledge my duty to disclose all infonnation known 
to bepiaterial to patentability which became available between a filing date of a prior application and the national or 
PCtRntemational filing date in the event this is a Continuation-In-Part application in accordance with 37 C.F.R. 
§l.#e). 

=P I hereby claim foreign priority benefits under 35 U.S.C. §1 19(a)-(d) or 365(b) of any foreign application(s) 
for patent or inventor's certificate, or 365(a) of any PCT international application which designated at least one 
coiiStry other than the United States of America, listed below and have also identified below any foreign application 
for patent or inventor's certificate having a filing date before that of the application on the basis of which priority is 
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in I hereby claim the benefit voider 35 U.S.C, § 1 1 9(e) of any United States provisional application^) listed 
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§ 1 12, 1 acknowledge the duty to tlisclose material information as defined in 37 C.F.R. § 1.56(a) which became 
available between the filing date of the prior application and the national or PCT international filing date of this 
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madjgare punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 
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§ 1.56 Duty to disclose information material to patentability. 

(a) A patent by its very nature is affected with a public interest. The public interest is best served, and trie most effective patent 
examination occurs when, at the time an application is being examined, the Office is aware of and evaluates the teachings of all information 
material to patentability. Each individual associated with the filing and prosecution of a patent application has a duty of candor and good 
faith in dealing with the Office, which includes a duty to disclose to the Office all information known to that individual to be material to 
patentability as defined in this section. The duty to disclose information exists with respect to each pending claim until the claim is canceled 
or withdrawn from consideration, or the application becomes abandoned. Information material to the patentability of a claim mat is 
canceled or withdrawn from consideration need not be submitted if the information is not material to the patentability of any claim 
remaining under consideration in the application. There is no duty to submit information which is not material to the patentability of any 
existing claim. The duty to disclose all information known to be material to patentability is deemed to be satisfied if all information known 
to be material to patentability of any claim issued in a patent was cited by the Office or submitted to the Office in the manner prescribed by 
§§ 1.97(b)-(d) and 1.98. However, no patent will be granted on an application in connection with which fraud on the Office was practiced 
or attempted or the duty of disclosure was violated through bad faith or intentional misconduct. The Office encourages applicants to 
carefully examine: 

(1) prior art cited in search reports of a foreign patent office in a counterpart application, and 

(2) the closest information over which individuals associated with the filing or prosecution of a patent application believe any 
p pending claim patentably defines, to make sure that any material information contained therein is disclosed to the Office. 

(bff Under this section, information is material to patentability when it is not cumulative to information already of record or being 
mad.ff)f record in the application, and 

y° c ( 1 ) It establishes, by itself or in combination with other information, a prima facie case of unpatentability of a claim; or 

LJ (2) It refutes, or is inconsistent with, a position the applicant takes in: 

= (i) Opposing an argument of unpatentability relied on by the Office, or 

S (ii) Asserting an argument of patentability. 

A pSma facie case of unpatentability is established when the information compels a conclusion that a claim is unpatentable under the 
pregidbderance of evidence, burden-of-pioof standard, giving each term in the claim its broadest reasonable construction consistent with the 
specification, and before any consideration is given to evidence which may be submitted in an attempt to establish a contrary conclusion of 
patgtability. 

(c) Individuals associated with the filing or prosecution of a patent application within the meaning of this section are: 

(1) Each inventor named in the application: 

(2) Each attorney or agent who prepares or prosecutes the application; and 

(3) Every other person who is substantively involved in the preparation or prosecution of the application and who is 
associated with the inv entor, with the assignee or with anyone to whom there is an obligation to assign the application. 

(d) Individuals other than the attorney, agent or inventor may comply with this section by disclosing information to the attorney, 
agent, or inventor. 



